Subject: APPN MIB Stuff

From: [email-masked]
Date: Tue, 29 Aug 95 10:29:34 EDT

Bob,

Yes, there are products that perform a periodic safe store (i.e. every X TDUs)
function.  There has been an architecture change made to TRS about a year or
so ago that allows the scenario you describe to occur without causing the
CP-CP session to come down.  Check out arch7945.psbin on the networking file
server.  This change was originally meant to accomodate nonsafe storing nodes,
but applies equally well to nodes that perform periodic safe store.

I'll briefly describe what this change is.
Using the scenario you described, if NNA receives a FRSN during the FRSN
exchange (it only does this during the FRSN exchange), that is higher than
its current FRSN, it increases its own FRSN to be one higher than that value.
It also sets the LAST_FRSN_SENT field in its ANCB entry for the partner node
to the value received.  So NNA won't bring down the CP-CP session, and also
keeps NNB happy, because when NNA sends its first TDU to NNB, the FRSNs match
what NNB expects from NNA.  Otherwise, NNB would also bring down that CP-CP
session.  Arch7945 explains in a little more detail how this works.

So the gist is that regarding the regulation of the "correctness" of FRSNs,
nodes are forgiving when first connecting to other NNs (i.e. FRSN exchange),
by accepting what their partner thinks was the last FRSN sent.  This
accomodates nonsafe storing and periodic safe storing NNs.  After the topology
exchange has occurred, any ensuing FRSN mismatches are either considered out
of order TDUs or protocol violations, depending on the mismatch.

Regards,
Tim

>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> appnNodeNnSafeStoreFreq     OBJECT-TYPE

Does any product really do an incremental safe store like this?
It can cause CP-CP session failure upon restart very easily.
Part of safe store is storing adjacent node last FRSN sent and received,
so that you reduce TDU exchange when the node comes back up.
Suppose NNA's safe store frequency is every 10 TDUs.  It does a safe store
at FRSN 10, and goes down after sending a TDU with FRSN 15 to NNB.
When NNA comes back up, on CP Capabilities exchange NNB will have claimed
to have last received FRSN 15 from NNA, which puts it ahead of what NNA
remembers sending.  NNA treats this as a protocol violation and will
unbind CP-CP sessions with sense 08A00006.
To make topology safe store work right, you have to either safe store
on every TDU, or safe store on shutdown only.
If someone can show me how incremental safe store can be made to reduce
TDU flows effectively, I'm for keeping this, but unless that happens this
should not be added to the MIB.

Bob Clouston

---

From: Bob Clouston <[email-masked]>
Date: Tue, 29 Aug 95 14:42:17 EDT

Tim,
I had missed that architecture item, and agree that it closes the CP-CP
session deact problem without having to resend the whole topology.

I still think that topology safe store has other disadvantages that may
well outweight its advantages, and that it shouldn't be base function.
Obviously other people disagree with me.  

Returning to the purpose of my original note to aiw-appn-mibs, 
I no longer have a problem with this object being added in the MIB.
One question for the MIB, what value should be returned if the node 
does not periodically safe store, but instead does it at shutdown only,
or perhaps also upon operator command?  From reading the VTAM doc, this
is how they implemented safe store.  

Tim, one comment on the architecture pages:  since periodic safe
store takes advantage of this as well as non-safe store, the comments on
pages 7-31, 7-37, and 7-38 about when the condition (adjacent node is ahead
of the local node in FRSN) occurs ought to be amended to reflect that this 
applies to periodic safe storing nodes as well non safe storing nodes.  The
condition is not obvious and periodic safe store implementers could easily
miss this and decide to skip this logic.

Thanks,
Bob